Prior processes used for servicing complex I/O adapters and control units required directly-connected servicing hardware - such as keyboards, floppy diskette or tape cassette drives, and display monitors. This servicing hardware was used to manually control the servicing of the adapter (or control unit), such as initiating the loading of code from a floppy diskette, starting execution of code, and handling error conditions occurring during operation. This servicing hardware correspondingly increased the manufacturing cost of the connected adapter or control unit.
Generally, the prior manual control process was done in several steps: First, the adapter or control unit had to be physically or logically removed from the system. This usually required commands to be issued from the directly-connected console to the adapter and its attached devices, so programs running in the system could not access the adapter and connected devices while servicing was being performed. It was important to prevent access to the adapter or control unit while it was being serviced because if an I/O operation was directed to it during a servicing operation, unpredictable operations (e.g. missing or lost completion status owed to the host program) may result with regards to that I/O adapter.
The following is an example of manual steps provided at a keyboard for controlling the process of loading microcode updates into an adapter or control unit. First, manual keying was needed to load the code typically from a directly-connected floppy diskette or cassette into a nonvolatile storage (such as a hard drive or flash memory) in the complex adapter or control unit. Once the microcode updates were loaded into nonvolatile storage, another manual keyboard step was done to reset the adapter or control unit so the updates could be transferred from the nonvolatile storage into a RAM storage. A final manual keyboard action was needed to start the operation of the adapter or control unit and its devices in order to put them back into service. In addition to all of this, if multiple adapters or control units need to be updated, this manual keyboard process had to be repeated for each of them.
In another service control scenario: when the adapter or control unit had a failure severe enough to prevent internal recovery actions from being successful, a manual keyboard process was used to readout detailed hardware state information from the adapter or control unit about its failure (called logging or logout), and then to manually initiate recovery actions from the keyboard. Typically, when an adapter or control unit detects a severe failure condition, such as a hardware failure or microcode problem, the failure is indicated on its console display or on a LED display, and its operations come to a halt. If the failure was not severe, a unit (device) check interruption signal was presented to the host operating system software with sense data indicating a limited amount of information about the malfunction.
However, the limited sense data alone may not give enough information to correct the problem. To acquire more detailed information about the failure, most control units have buttons and/or switches on a console for indicating to a person who can manually initiate actions of dumping traces and other-pertinent error information for a logout.
The logout information may be received on a storage medium such as a floppy disk, and then it may be hand carried to a computer system to be analyzed. To attempt to recover from the failure usually required manual actuation of an IPL (initial program load) button on the adapter or control unit to reinitialize it. For intermittent failures, the IPL may get the adapter or control unit up and running so it can be used while someone is analyzing the dump data to pin point the problem.
Accordingly in the known prior art, complex adapters and control units required manual intervention at directly-connected service controlling hardware to force logouts, to reset the adapter or control unit, and to reinitialize and start its code.